Repository navigation
fix(social): ask the credentials leaf before onboarding - #2132
Conversation
A link or a directory at flybot-social.json used to be found only when the newly minted token was written back, after onboardHome had already asked the server for a home. Every start on such a path therefore created a home it could never keep and dropped the token. The leaf check now runs before the onboarding call, through the same predicate and the same bot/refused sentence the write uses (one helper, so the two cannot drift).
|
@Birfy — review request at this tip. Tip What it fixes (#2130). Red first on base Verify at this tip ( 3 files +66/−8, |
|
Verdict: PASS at b0a8a43 Ran at this tip: The plugin's harness file here is Order — the refusal really precedes the home (1). Red first, on the observable behaviour (4). The same tip test file over the base No residue (2). Everything above
Docs (5). Checks at this tip (all terminal): Residual, accepted as the author states it: the leaf is read twice — before onboarding and again at the write — so a link that appears during the round trip is still refused at the write, with that home already spent. That is the pre-existing window, not a new one. |
Fixes #2130
Written-by: Dev-2
Owner: Dev-2
Reviewer: Birfy
Claim-Id: 011d0b0822ce48f7985628ccfede10a7
Branch: dev/2-391-credential-order
Base: e6dfffe
Tip SHA: b0a8a43
What changed
startSocialasked whether the credentials path can be written only after it had already asked the server for a home, so a dangling link (or a link pointing at some other file in the home) cost one orphan home and one discarded token on every start, and the user saw onlystart failed: Not saved: ….plugins/social/src/social.js— the refusal thatwriteCredentialsspelled inline is now one helper,refuseLeaf(path)(:491), which keeps both the predicate (leafWritable) and the sentence (bot/refused,Not saved: … is not a plain file of its own…);writeCredentialsthrows it (:499). The onboarding branch ofstartSocialruns the same check on its first line (:4714), beforeawait onboardHome(...), and throws the same refusal. A start that cannot keep the token no longer spends a home; a start with no credentials path configured is untouched, and a start whose path is writable behaves exactly as before.plugins/social/test/credentials-leaf.test.js— the ordering is pinned with a counting fakefetch: the linked shapes reject withbot/refusedand the server is asked for a home zero times, while the control shapes (absent path, plain file) still onboard exactly once and write the token.docs/subsystems/social.md— the owned doc now says where the leaf is read and why it moved: onboarding is a round trip that creates a home on the server, so it is the last thing a start that cannot keep its token should do.3 files, +66/−8.
Red first
On base
e6dfffewith only the new test added,TZ=UTC node --test test/credentials-leaf.test.jsinplugins/social/: 10 tests / 9 pass / 1 fail.The old order asked the server for a home (one
fetchto/v1/onboard/flybot) and only then refused the write. The same case covers both linked shapes — a dangling symlink and a symlink to another file in the home — and assertsbot/refused, the link left as it was, and no new file in the home.The control sits in the same file and was already green on the base, so the fix cannot pass by refusing everything:
an absent or plain credentials path still onboards exactly once and writes the fileasserts one onboard and a token written as a plain file, for a credentials path that is absent and for one that is a plain file holding something that is not credentials.Verification at the tip
Tip SHA:
b0a8a4302fa0466e4d312cfdcb499db4e12f7a5a(tree9f3cb93a76cc80e59ad542d462f05f0479480695, single parente6dfffeeb1ea1a50ab4e0695db9404b65528140f; the push helper rebuilds the commit through the Git Data API, so the tree is the one verified locally).Ran
TZ=UTC ARCH_DOCS_BASE=e6dfffe npm run verifyon a clean, committed tree — exit 0:plugins/social553 (552 pass, 1 skip), includingcredentials-leaf10/10plugins/tree127 (126 pass, 1 skip),plugins/timeline140 (139 pass, 1 skip),plugins/workflow338,.github/scripts598,interop37,live-e2e24 — no failuresarch-docs: OK (3 changed file(s))checkandcanonicalpass andgenerateis a no-op;build-client --checkpassesNot run (and why): no live host and no bench instance — the ordering is asserted against a fake
fetchand a temporary home, so the claim is about the calls the plugin makes, not about a real server's state afterwards.Scope
readCredentials(it still returnsundefinedfor both linked shapes, which is what enters the onboarding branch), the write path itself, and the wording of the refusal.Checkpoint
{ "pr": 2132, "claim": "Dev-2", "issue": 2130, "summary": "`startSocial` asked whether the credentials path is writable only after `onboardHome` created a home on the server and returned a token, so a dangling or outside-pointing link spent one orphan home and one discarded token per start. The leaf test now runs before the onboarding call, through the same `refuseLeaf` helper the write uses, so a start that cannot keep the token never spends a home and the refusal is unchanged. The tests count fetches: a linked path rejects with `bot/refused` and zero homes asked for, while an absent or plain path still onboards once and writes the file.", "files": [ "plugins/social/src/social.js", "plugins/social/test/credentials-leaf.test.js", "docs/subsystems/social.md" ], "checks": { "ran": "TZ=UTC ARCH_DOCS_BASE=e6dfffe npm run verify (clean tree)", "result": "green", "at": "b0a8a4302fa0466e4d312cfdcb499db4e12f7a5a" }, "next": "none — ready for review at this tip" }